Kubernetes Volumes configuration

danger

Shared Exivity volumes must use ReadWriteMany when pods can run on more than one node.

info

Storage requirements depend on cluster size.

• Multi-node clusters require RWX-capable shared storage. NFSv4 is supported because Exivity needs file locking (which is not reliably supported in NFSv3, the default for many NFS deployments). CSI-backed storage such as Longhorn can also be used when it supports RWX volumes.
• Single-node clusters do not require RWX. Setting storage.sharedVolumeAccessMode: ReadWriteOnce and using a local-path or HostPath provisioner is sufficient because every Exivity pod is scheduled to the same node. RWX storage is only needed if you plan to scale to multiple nodes.
• File locking is essential for correct operation and data integrity on any shared storage backend.
• For detailed setup, Helm configuration, and production database recommendations, see Helm Chart Configuration & Dependencies.

Third-party storage

Storage systems such as NFS, Longhorn, cloud file services, and CSI drivers are third-party infrastructure. Exivity relies on compatible RWX storage, but you are responsible for selecting, sizing, operating, backing up, monitoring, and supporting the storage platform.

App specific FS

Most services require a number of directories, as well as a valid config.json file. Where possible, these are provisioned for each process individually, without sharing filesystems between services.

Config.json

Services require a config.json file to be mounted under /exivity/home/system to work. For services controlled by Merlin, these configs include the config for the Merlin app in the container. Applications that don't rely on Merlin for their operation read the required config from the default config file named app-config-default. In either case, these files are Kubernetes-native ConfigMap objects mounted to the correct path.

	exivity-{{ app }}-log	app-config-default	app-config-{{ app }}
chronos	x	x
edify	x		x
glass
griffon	x	x
horizon	x		x
pigeon	x		x
proximity-api	x	x
proximity-cli	x		x
transcript	x		x
use	x		x

To facilitate the inbuilt log viewing in the UI, all of the log volumes are mounted in the app they service, and in proximity-api.

Shared FS

Requirements

A number of services in the application use shared filesystems.

They need to be deployed with the volumes set to ReadWriteMany or scheduled to the same node. Ideally shared filesystems are only applied when strictly necessary.

	exivity-etl-config	exivity-exported	exivity-extracted	exivity-import	exivity-report
chronos
edify	x		x		x
glass
griffon
horizon
pigeon
proximity-api	x	x	x	x	x
proximity-cli	x	x	x	x	x
transcript	x	x	x	x	x
use	x	x	x	x

Accessmodes

Since the application requires shared volumes between services, any cluster that is suitable for a deployment must have at least one StorageClass that allows the ReadWriteMany access mode on PersistentVolumes.

Google Kubernetes Engine (GKE)

Public cloud providers generally do not provision clusters with a StorageClass with a ReadWriteMany access mode by default. In the case of GKE, a solution is offered by way of a managed NFS solution named Filestore.

Here are several methods for using Filestore (FS) storage in a GKE cluster. This is not an exhaustive list.

• Install the CSI driver and provision storage automatically with a storageclass. Every PV will get mounted to a single instance, minimum sizing is 1Ti. More expensive than options using only a single Filestore instance. The advantages are automation, backups, performance.
• Add an in-cluster NFS mounted on a FS instance. After creating the FS instance, install the linked helm NFS subdir chart using the IP and path set for the FS instance on creation. The correct values can be found in the details page of the FS instance in the GKE console.

For step-by-step NFS and storage class setup, see Helm Chart Configuration & Dependencies.